0x057F24:
	-Gets VarMem pointer
	-Loads map ID from memory
	-Loads $0821F274 (map main params table); adds 5 + (ID*32); loads word at that spot

0x05A664: Routine for processing NPC/sprites from map feature data
	r0 = MapMem pointer
	r1 = ?
	r2 = Sprite Index (map-based sprites seem to start at index 0x2)
	r3 = Map sprite ID
	stack params have data from sprite object in ROM:
		+$00: X-coord
		+$04: Y-coord
		+$08: Starting orientation/animation frame
		+$0C: event index
		+$10: Interior/Exterior sprite
		+$14: Movement speed
	Some of these params are transferred to this function's stack params
	Gets offsets for sprite's entries in MapMem and VarMem
		-Converts short coords to long coords, stores them and starting anim frame to VarMem data
		-Stores 0x0 to MapMem entry +$64,$66, short coords to $74/$76, $78/$7A (current/destination coords)
	Next, gets MapMem+$224, MapMem +$801C, the unknown r1 param, and sprite ID; branches to $8067270
		(some sort of checking routine?)
	If returned 0x1 (usual outcome?):
		-Store map sprite ID to MapMem struct
		-With params of MapMem+$801C, sprite ID, MapMem struct +$2C, branch to $675B8:
			(stuff for fetching sprite GFX pointer / GFX params?)
	0x05A6E2: storing collision bitfield halfword; why do some sprites not block movement?
		-answer lies in a different subroutine

0x05AFC4: Part of map data loading; base routine of sorts
	-Allocates loads of stack space
	-Map data from ROM will be stored to VarMem+$7E1C, or VarMem+$7C7C depending on the chunk's identifier
	-Map data is stored to RAM in 8-byte chunks, but not all chunks are 8 bytes in ROM
	
	0x05B17E: Loads event pointer depending on map ID(!); will branch to store to IRAM
	Next, reads the event commands from that script offset until that script finishes

0x05B1F0: A map setup routine...splits into several sections depending on input values
	-Used for map data chunks 0x2, 0x3, 0x4

	Stores data from map data chunks to map memory
	Store r2 to MapMem+$00
	curr+1 = MapMem storage + 1 (byte)
	curr+2 = MapMem storage + 2 (halfword)
	If input from r3 was 0x0, store 0x0 to currMem+1 and +2; does nothing, but blocks NPCS
	If input was 0x1-0xF9D, store 0x2 to currMem+2 and (input - 0x1) to currMem+2 (exits)
	If input was 0xF9E, store 0x06 to currMem+1 and 0x0000 to currMem+2 (Soul of Chaos dungeon entrance?)
	If input was between 0xF9F and 0x1193, store 0x04 to curr+1 and input to curr+2 (Special event?)
	If input was between 0x1194 and 0x1387, store 0x03 to curr+1 and (input - 0x1194) to curr+2 - Spiked squares data
	If input was larger than 0x1387, store 0x04 to curr+1 and input to curr+2 (display text / play event of input ID)
		-There are subdivisions within this range that are sussed out later when triggered, in 0x5B9E4

0x0640E4: Checks whether to change music when changing maps
	-Loads current and next maps' music IDs for this purpose
	-Also checks for map 0x57 (Mt. Duergar), to clear the smithing overlay sound


0x0669B8: Checks for spiked tiles on your current/destined position?
	Checks 0x3F or 64 entries -> only 64 map data chunks allowed per map?
	
0x0667D4: Starts by storing map start event pointer to IRAM
	-does some misc storing...including a one-word CPUSet...

0x067B24: Big routine that handles map tile/tileset loading
Herein map tileset ID is loaded
  0x67B60: Also loading unknown map param; if nonzero, use fixed params here
  0x67B8C: Also loading map tile data; branches to 0x69290

0x068644: Here, a map's data is read and the appropriate tiles/collision data/etc is loaded
	r1: X-offset to start loading from...value changes depending on direction moved also
	-Run when loading a map and after every step to redraw the map
	-Map tile drawing is done row-by-row, top to bottom, left to right
	$686F6: r5 = horiz. start (add 0xE if moving to the right); gets incremented up to map width
		r8 = vert. start (add 0x8 if moving down)
		multiply r8 by map width, add to r5, add to (decompressed) map data pointer
		Load the tile ID halfword there
	-Upon loading a map tile ID halfword:
		-Take low 4 bits, multiply by 4
		-Take upper 12 bits, multiply by 256
		-Add together, add to (decompressed) TSA pointer
		-If map type is 0x1 and you're outside a room, add 0x20 lsl 0x7 (0x1000); save in r12
			-This way, if you're in a room or not you'll load different GFX
		-Navigate to next tile data to overwrite(?) r10 lsl 0x5 + r7 lsl 0x1 + 0x4C + r4; save in r3
		-load [r12], [r12+2] and store to [r3], [r3+2] (top left/right of tile)
		-load [r12+0x80], [r12+0x82] and store to [r3+0x40], [r3+0x42] (bottom left/right of tile)
			-Storing to tile map as 'background' tiles
			-Top nybble is palette ID, rest are tile ID
		-load [r12+0x40], [r12+0x42] and store to [r4 + 0x84C + count*2], [r4 + 0x84E + count*2]
		-load [r12+0xC0], [r12+0xC2] and store to [r4 + 0x88C + count*2], [r4 + 0x88E + count*2]
			-For 'foreground' tiles drawn in front of the above tiles (eg for armor stands)
			-Same format: top nybble as palette, rest as tile ID

0x069290: Given a map tile data pointer, do the needful
	-Decompresses map and stores to VRAM; gets pointer to map data in VRAM
	-Stores the 8-byte header contents to memory, then adds 8 to the pointer and stores too

0x069348: Routine that draws a map's tile data out?
	-First


Having the Mystic Key clears all NPCs with a dialogue index of 0x1F4A0400 when the map is loaded?